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The Eureka-147 Digital Audio Broadcasting (DAB) stan- 
dard defines the 'dynamic labels' data field for holding in- 
formation about the transmission content. However, this 
information does not follow a well-defined structure since 

, it is designed to carry text for direct output to displays, 
for human interpretation. This poses a problem when ma- 
chine interpretation of DAB content information is desired. 
Extensible Markup Language (XML) was developed to al- 

, low for the well-defined, structured machine-to-machine 
exchange of data over computer networks. This article 
proposes a novel technique of machine-interpretable DAB 
content annotation and receiver hardware control, involv- 
ing the utilisation of XML as metadata in the transmitted 
DAB frames. 

I. Introduction 

THERE are various digital audio broadcast standards in 
existance. The European Eureka-147 DAB standard 
is described in this article. This standard offers advanced 
methods for source coding, channel coding, and modula- 
tion, with the DAB frames having fields defined for both 
data and audio. The main advantages of this standard over 
FM are CD-quality audio, a 'Single Frequency Network' 
throughout the coverage area, data transmission capabil- 
1 ity, spectrum usage efficiency, and suitability for mobile 
reception. 

However, one limitation of this standard is that it does 
not define structured data fields for annotation of the au- 
dio content. The 'dynamic-labels' field is used for carrying 
transmission content information, such as artiste name and 
song title. This field does not impose a well-defined struc- 
ture on the data it holds, since it is designed to carry text 
that will be directly displayed to the end-user. As such, it 
has limited machine interpretability. 

Machine interpretability of received data will allow for 
powerful and flexible applications at the receiver; different 
receivers may choose to decode different parts of the bit- 
stream, or effect different responses to the same received 
data, depending on the application. 

Extensible Markup Language (XML) is a specification of 
the World Wide Web Consortium (W3C) that allows for 
the description (or markup) of data using a set of well- 
defined tags. The utilisation of XML gives data a struc- 
ture that allows for machine interpretation of that data. 
Its main application thus far has been in the exchange of 
business information over the internet. 
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The need for structured annotation of DAB content, and 
the ability of XML to provide structured annotation of 
data, imply a synergistic combination of both technologies 
in a novel application of XML and an innovative technique 
of DAB transmission content description - the transmission 
of XML over DAB. 

This article begins with an introduction to the 'Cam- 
pus DAB' initiative undertaken by NgeeAnn Polytechnic, 
which led to the innovation of XML over DAB' as a base 
technology. Next, a description of how non-audio data is 
transmitted in DAB frames is given. It is shown how this 
leads to the problem of unstructured content annotation. 
The following section explains how XML is designed to 
give data a well-defined structure, and discusses the XML 
schema and messaging protocol developed for both anno- 
tation of DAB transmission content and control of the re- 
ceiver hardware. Next, the necessary transmission frame 
header settings and extensions to the existing DAB stan- 
dard to allow for transmission of XML are discussed. Fi- 
nally, the architectural set-up and software deployment as 
developed in the working prototype system are analyzed. 

II. The Campus DAB Initiative 

Traditionally, DAB has been used by radio broadcast- 
ers who wish to offer their listeners the clarity of digital 
audio and the transmission of data, such as weather fore- 
casts and traffic information, alongside that audio. The 
DSP Technology Centre of NgeeAnn Polytechnic has taken 
DAB to the next level of application, under its 'Campus 
DAB' initiative. This project will see DAB receivers de- 
ployed at various locations throughout the campus, each 
of which selectively decodes a particular subchannel of the 
DAB transmission, and performs an action on the decoded 
data depending on the receiver's location and purpose. For 
example, a DAB receiver located at the canteen may be 
configured to decode the 'Campus Radio' subchannel and 
output the audio through speakers, while another one lo- 
cated at a lift lobby may be used to decode and display 
announcement messages transmitted on another subchan- 
nel of the same DAB transmission ensemble. Yet another 
receiver located at a study area may decode e-learning con- 
tent on a PC terminal. 

The complication arises from the fact that different data 
meant for different receivers may be transmitted on the 
same subchannel; for example, an announcement message 
meant for the Mathematics Department should be decoded 
by a receiver located at that department, but not one lo- 
cated at the Engineering Department. This means that 
the DAB receivers need to be able to interpret the received 



ARXIV.ORG 



2 



data, and decide on a course of action depending on that 
data. This led to the development of the 'XML over DAB' 
concept that has since been implemented and tested as a 
prototype system at the DSP Centre. The next sections 
describe DAB data transmission and this prototype imple- 
mentation. 

III. DAB Data Transmission 

Data is transmitted in the Programme Associated Data 
(PAD) field of each DAB audio frame, as shown in Figure 
^ A data object to be transmitted is split up into multiple 
segments, so that different segments can be sent out in the 
PAD fields of multiple DAB audio frames. At the receiver, 
these segments are extracted and combined to form the 
complete data object. 



MPEG audio 



PAD 



Single DAB Audio Frame 



Fig. 1 

A Single DAB Audio Frame 



The two main methods of data transmission in the PAD 
field are Dynamic Labels and Multimedia Object Transfer 
(MOT) objects [T]. 

Dynamic Labels hold audio descriptive information for 
presentation to the end-user, such as song title and artiste 
name. The data is sent as unstructured strings of ASCII 
characters, for direct display by the receiver. The absence 
of a well-defined structure is insignificant, since the Dy- 
namic Labels Field has been defined to carry information 
for human interpretation. However, a problem arises when 
attempting machine interpretation of the Dynamic Label. 
In this case, the unstructured information poses a barrier 
to the ability of the machine to identify portions of the 
Dynamic Label with their corresponding intended use. For 
example, the dynamic label "Dancing Queen by ABBA" 
can be easily understood by a human being as describing 
a song called "Dancing Queen" sung by "ABBA". To a 
machine, on the other hand, there is no way of identify- 
ing the purpose of one segment of text from another in 
an unstructured block. In this case, "ABBA" will have 
an equal probability of being a song title as "Queen" or 
" Dancing" . This illustrates the limited use of the Dynamic 
Labels Field in the machine-interpretable annotation of a 
DAB transmission. 

The MOT protocol has been defined for the transmission 
of data objects, such as JPEG image files. The file to be 
transmitted is segmented into Data Groups, as shown in 
Figure [21 These Data Groups are then sent into a PAD 
encoder for transmission in the DAB audio frames. The 
MOT specification currently defines a limited, extensible 
set of MOT object types comprising of the Content Type 
and ContentSubType fields of the MOT Object header. 
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Fig. 2 

Building the MOT Data Group 



This explanation of the DAB non-audio data transmis- 
sion capability shows that only unstructured audio annota- 
tion information can be sent in the Dynamic Labels Field. 
MOT objects, however, offer an avenue for transmitting 
data objects that can be used for providing structured au- 
dio annotation information. How this can be done is de- 
scribed in Section Ivl 

IV. Using XML 

The XML specification was created by the W3C to de- 
fine a markup language that can be extended to suit the 
context of the data it describes. XML is designed to be 
used for the marking-up of data in a machine-to-machinc 
information exchange environment. The mark-up is done 
with 'tags' that designate the properties of the enclosed 
data. This gives the data a well-defined structure that al- 
lows for machine interpretation of that data. However, it is 
the extensibility of XML that gives this markup language 
its true power - by utilising this capability, different sets of 
tags can be defined for different uses of data. 

The structured data annotation capability of XML, its 
inherent design for machine interpretability, and the exten- 
sibility of the language, imply that an application of XML 
can be defined for annotation of the DAB audio bitstream. 
This will give the transmitted data a well-defined structure 
that allows machines to interpret, understand and react to 
audio content. 

To use XML in such an environment, two main areas 
have to be looked into: the development of an XML schema 
that serves this purpose (i.e., the extension of XML), and 
the utilisation of a suitable XML messaging protocol. 



A. The XML Sche 



DABml 



A schema declares the vocabulary (tags) of an XML ap- 
plication, as well as the usage of these tags. It was decided 
that the schema defined has to offer the ability to describe 
the transmitted bitstream content, and specify the reaction 
the machine should exhibit to particular content received. 

As a result, the DABml schema has been designed with 
four main tags: 

• <audioContent> describes the content of the audio por- 
tion of the DAB transmission, such as the song title, artiste 
name and music genre; 
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• <dataContent> describes the content of the non-audio 
data portion of the DAB transmission, such as image files, 
web pages, etc; 

• <hardwareControl> controls the DAB receiver hardware 
and the computer to which the receiver is attached. Such 
controls may include turning down the volume or recording 
a subchannel to the PC's harddisk; 
. <behaviours> pulls together the descriptive <audioContent>' htt P : //schemas . xmlsoap . org/soap/encoding/"> 
& <dataContent> tags, and the reactive <hardwareControl> 
tag, to define the response to particular content received. 

The UML (Unified Markup Language) static structure 
model of parts of the DABml schema is given in Figure [3] 



the artiste name and song title as 'ABBA' and 'Dancing 
Queen' respectively. 



<SOAP-ENV : Envelope xmlns : SOAP-ENV= 
"http : / /schemas . xmlsoap . org/soap/envelope/" 
SOAP-ENV : encodingStyle= 



<SOAP-ENV:Header> 
</SOAP=ENV:Header> 



«XSDattribute» ReceiverlD : string 



hardwareControl 



audioContent 

«XSDattribute» 
action : actionKind = set 



news 


local [0.." 


: string 


regional [0..* 


: string 


world [0..* 


: string 


political [0..* 


: string 


technology [0..* 


: string 


sports [0..* 


: string 


entertainment [0..* 


: string 


others [0..* 


: string 



programme 


name [0..*] 


string 


deejay [0..*] 


string 



commentary 


occasion [0..*] 


string 


event [0..*] 


string 


party Involved [0..*] 


string 


venue [0..*] 


string 



genre [0..*] : musicKind 
artiste [0..*] : string 
songTitle [0..*] : string 



validity 



start : datetime 
end : datetime 



advertisement 


product [0..*] 


string 


company [0..*] 


string 



Fig. 3 

UML Static Structure Model of the four main DABml tags 



B. The XML Messaging Protocol 

To use XML in the exchange of information between a 
sender and a receiver, a well-defined communications pro- 
tocol has to be utilised. This XML messaging protocol lays 
down the rules of communications between parties, so that 
messages are received as intended by the sender. 

There are multiple XML messaging protocol specifica- 
tions in existance. SOAP is one such specification that 
is gaining great momentum due to its open standard, 
widespread industry support, and simple design. As such, 
SOAP was selected as the DABml messaging protocol. 

SOAP messages are composed of an outer envelope that 
encloses a header and a body. The header contains meta- 
data about the rest of the message, while the body holds 
the message payload. The example below shows how SOAP 
can be used to transport a DABml message which specifies 



<S0AP-ENV:Body> 

<dabml : DAB xmlns : dabml= 
"http://location/dabml/"> 
<audioContent> 

<artiste>ABBA</artiste> 
<songTitle>Dancing Queen</ songTitle> 
</audioContent> 
</dabml : DAB> 
</S0AP-ENV:Body> 

-c/SOAP-ENV : Envelope> 



V. Transmitting XML over DAB 

The XML message to be transmitted has to be inserted 
into the PAD field of DAB Audio Frames, of the particular 
subchannel concerned. To notify the receiver that such a 
message is available, information is inserted into the Fast 
Information Channel (FIC). This requirement is not fully 
satisfied by the DAB standard However, the standard 
has defined several fields as being 'Reserved for future defi- 
nition'. By utilising these fields to extend the current state 
of the DAB standard, the requirements for transmission of 
XML over DAB can be satisfied. 

Another requirement is indication of the interval during 
which an XML message is 'valid'. This period of valid- 
ity can, for example, indicate when the information in the 
XML message applies to the audio content. This allows for 
earlier transmission of a message that will be effective only 
at a specified later time. 

The requirements for transmitting XML over DAB, and 
how these requirements are met, are detailed below: 

A. User Application Information 

As shown in Figure 01 the DAB transmission frame is 
divided into the FIC and the MSC (Main Service Channel). 
The FIC holds information about the MSC, which in turn 
holds all the subchannels. Information in the FIC is carried 
in FIGs (Fast Information Groups), each kind of which 
is identified by a type and extension in the format FIG 
TYPE/EXTENSION. 

FIG 0/13 ('User Application Type') allows for signaling 
of the kind of data being carried in each subchannel. This 
is so that the user application will be able to use the correct 
decoder to extract the information from that subchannel. 
It is required that a User Application Type be defined for 
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Structure of the DAB Transmission Frame 



XML messages. The bit representation of '00000000110', 
defined in the DAB standard as 'Reserved for future defini- 
tion', has been utilised to represent 'MOT XML Message' 
in this prototype implementation. 

B. MOT ContentType / ContentSubType 

For the MOT decoder to decide where to channel a de- 
coded MOT object, there must be some technique of sig- 
naling the type of data in the object. The MOT specifi- 
cation defines the 'ContentType', 'ContentSubType' and 
'ContentName' fields of the MOT object header core for 
this purpose, as shown in Figure 

Variable Size 





MOT Object Header 


Body 




7 Bytes 


Variable Size' • . 




Header Core 


Header Ext 





take the form of a PC which is connected to the DAB re- 
ceiver via the Universal Serial Bus (USB). 

If this PC is connected to the network, the possibility 
arises for remote communications with the DAB receiver. 
In this case, that PC takes on the role of a server, while 
any other PC on the network plays the client. 

Since SOAP has been designed for client-server commu- 
nications over computer network, the client in this set-up 
can utilise the same SOAP protocol and XML schema as 
that transmitted over the air, to communicate with the 
DAB receiver. The origin of the message destined for the 
receiver is transparent to the part of the server application 
that interprets SOAP - whether the message arrives from 
a client over the network or from a broadcast over the air 
is of concern only to the higher layers. 

A. Deployment of Resources 

The set-up of the prototype system is illustrated in the 
UML Deployment Diagram of Figure 



Deploys 
Server-side Application 
SAX XML Parser 
ASP Server 
" DAB receiver driver 
SOAP Toolkit Library 



Deploys 
Client application 
SOAP Toolkit Library 



ContentSubType 



ContentName 



Fig. 6 

UML Deployment Diagram of the set-up 



Fig. 5 

MOT Object Structure 



To transmit XML, the MOT Header 'ContentType' and 
'ContentSubType' will have to contain '000000' ('General 
Data') and '000000001' ('MIME/HTTP') respectively, so 
that the Header Extension can contain the 'ContentName' 
string of 'TEXT/XML'. This ContentName will identify 
the presence of XML annotation to the receiver. 

C. Object Validity 

As required for the synchronized interpretation of XML 
messages, and as offered by the MOT specification, the va- 
lidity of MOT objects is signaled by the parameter data 
field of the MOT object's header extension. The param- 
eters 'Start Validity' and 'ExpireTime' are coded in UTC 
format, and represent the start and end of the validity pe- 
riod respectively. 

VI. The System Architecture 

Since SOAP is used to communicate with the DAB re- 
ceiver, a computing platform is needed to extract and inter- 
pret the SOAP message before sending lower-level instruc- 
tions to the DAB hardware. This computing platform may 



A.l DAB Receiver 

• The DAB Receiver is connected to the Server via the 
USB. The Server controls and receives data from the re- 
ceiver over this bus. 

A. 2 Server 

The server is the link between the DAB receiver and 
the 'outside world'. All DABml SOAP messages are inter- 
preted and executed by the server. To do this, the following 
software are deployed: 

• Server-side Application: This application runs various 
threads to extract SOAP from the subchannel bitstream, 
interpret the message, and perform necessary hardware 
control; 

• SAX XML parser: It is used by the server-side appli- 
cation to parse the XML in the SOAP message, so that 
pertinent information can be extracted; 

• ASP Server: This is the 'listener' that receives messages 
from network-based clients and passes them to the server- 
side application; 

• DAB Receiver Device Driver: The driver abstracts bus 
communications between the DAB receiver hardware and 
the server. The server-side application utilises the driver 
for all communications with the DAB receiver; 
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. SOAP Toolkit Library: A SOAP Toolkit is a library 
which exposes a set of APIs to allow for transparent en- 
coding and decoding of SOAP messages. The server-side 
application uses this library to send and receive SOAP mes- 
sages over the network. 

A. 3 Client 

The client communicates with the server using DABml 
SOAP messages. These messages may involve requests for 
DAB subchannel content information, or control of the 
hardware. The following are deployed at the client: 

• Client Application: This software presents an interface 
to the end-user, which displays information about the DAB 
services and accepts input from the user. It acts as a 'fron- 
tend' for communications with the DAB receiver, making 
it transparent to the end-user that the receiver is not con- 
nected to his PC, but is instead remotely accessed over the 
network; 

• SOAP Toolkit Library: Just as for the case of the server, 
the client uses this set of APIs to encode / decode SOAP 
messages for communications over the network. 

B. How It Works 

Figure [7| shows the main layers of software and hardware 
involved in the prototype set-up developed. 
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Fig. 7 

Main Hardware and Software Layers of the Set-Up 



The server-side application consists of three threads of 
execution, labelled on Figured as 'Thread 1', 'Thread 2' 
and 'Thread 3'. 

B.l Thread 1 (Server-Side Application Main Thread) per- 
forms the following tasks: 

• It is the first thread started when the application is 
loaded. Correspondingly, it has to start the other threads; 

• SOAP messages received from either the DAB broadcast 
or the client are parsed using SAX, interpreted, and pro- 
cessed; 

• If necessary, it builds up SOAP messages for reply to the 
client through the SOAP Toolkit Library; 

• It monitors the set of 'behaviours' defined, and triggers 
a reaction whenever a message of interest is received. 



B.2 Thread 2 (DAB Subchannel Bitstream SOAP Extrac- 
tor) performs the following tasks: 

• Extracts and builds up the MOT object to obtain the 
SOAP message; 

• Signals the Server-Side Application Main Thread and 
passes it the new SOAP message decoded. 

B. 3 Thread 3 (Hardware Control) performs the following 

tasks: 

• All hardware access is done by this thread. PC resources 
are accessed via the Operating System (OS) API. The DAB 
receiver hardware is accessed via the device driver; 

• It performs all necessary initialisations of the DAB hard- 
ware upon startup, such as tuning to a default ensemble 
and service; 

• It engages in its own automatic monitoring and control 
of the DAB receiver, such as adjustment of the Automatic 
Frequency Control (AFC) to cater for variations in the re- 
ceived signal; 

• It receives hardware-control messages from the Server- 
Side Application Main Thread, and performs the corre- 
sponding operations on the hardware. 

• It saves decoded MOT objects from the DAB subchannel 
bitstream to the PC's harddisk, the URLs of which are 
returned to the Server-Side Application Main Thread. 

Figure|Hlshows a UML Sequence Diagram that illustrates 
an example of the operations that occur at the DAB re- 
ceiver, the server, and the client. It also shows the calls 
and messages exchanged among them. 

In this scenario, the server initialises the DAB receiver 
and requests a default subchannel. This subchannel bit- 
stream is sent to the server at regular intervals, upon which 
SOAP (if present) is extracted and interpreted. Some time 
later, a client connects to the server and requests informa- 
tion about the transmitted audio and data. This informa- 
tion can, for example, be used as service information for 
display to the end-user. The client then sends a new user- 
defined behaviour setting to the server, to which the server 
responds with a message indicating success in adding the 
new behaviour. Next, the server invokes behaviour reac- 
tions that operate on both the server itself (server-centric 
reaction, such as saving a bitstream to the harddisk) and 
the DAB receiver (device-centric reaction, such as turning 
up the volume). Some time later, the client sends the server 
a <hardwareControl> message (such as switching of sub- 
channels). The server correspondingly acts on the receiver, 
and relays the result of the operation back to the client. 

This diagram also shows that all communications be- 
tween the server and the client utilise SOAP, and all com- 
munications between the client and the DAB receiver have 
to go through the server. 

C. The Prototype Implementation 

The system architecture described in this section has 
been implemented as a prototype at the DSP Centre, to 
test its feasibility for deployment under the 'Campus DAB' 
initiative (described in Section ITTf> . 
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Fig. 8 

UML Sequence Diagram of Control-Flow XML Utilisation 
Example 



It is planned that the 'Campus DAB' project will utilize 
PC-based DAB receivers, since PC resources such as hard- 
disk space for data storage and the visual display monitor 
are desired at each deployment location. 

The prototype has therefore been tested with both the 
client and server running on the same PC (to simulate a 
deployment location), as well as on separate PCs (to simu- 
late a remote client being used to administer a deployment 
over the network). 

The prototype implementation has been shown to be ide- 
ally suited for the 'Campus DAB' initiative. In particular, 
the ability to remotely program the server at any deploy- 
ment point from a client on any PC is a boon for adminis- 
tration of the Campus DAB network. 

VII. Conclusions 

This article has presented a novel technique of DAB con- 
tent annotation and receiver hardware control involving the 
use of SOAP embedded in DAB transmission frames. The 
transmission of PAD in DAB has been described, and the 
problem of unstructured data exchange explained. The 
features of XML that allow for well-defined, structured 
machine-machine exchange of data has been illustrated, 



and the capabilities offered by a marriage of XML and 
DAB explained. An XML schema (DABml), which allows 
for both DAB content annotation and receiver hardware 
control, has been proposed and implemented. The client- 
server architecture set-up as demonstrated in the prototype 
test system has been discussed and shown to be suitable 
for campus-wide deployment under the Centre's 'Campus 
DAB' initiative. 

A. Lessons Learned 

One trade-off of this proposal is that XML is verbose 
text-based metadata that can significantly increase the 
overall size of data to be transmitted. This results in a 
lowering of the efficiency of the transmission. However, the 
fact that XML is just text brings about the advantage that 
it can be sent over the network without being a cause of 
concern for firewalls. This allows the same markup lan- 
guage and protocol to be used for messages sent either over 
the broadcast transmission or over the computer network 
to PCs beyond the firewall. 

A mistake made in an early design and implementation 
was to require transfer of XML received over the air to 
the client for analysis, with the 'behaviours' also stored 
at the clients. The rationale behind this idea was that the 
client-orientation would allow a single receiver to be shared 
among different clients, each of which picks out only the 
data it is interested in from the entire received DAB trans- 
mission channeled to each client. The problem encountered 
was that by performing subchannel selection and extrac- 
tion at the client, followed by further MOT object extrac- 
tion and decoding, and perhaps even decoding and output 
of the MPEG audio, the client PC processors were insuffi- 
ciently powerful enough to handle all these tasks resulting 
in buffer overruns and loss of data. It was found that let- 
ting the DAB receiver hardware perform the subchannel 
selection and audio decoding, with the server receiving a 
particular subchannel for MOT data extraction / storage, 
and the client only involved in control and data request, 
resulted in an optimal distribution of processing-intensive 
tasks - although this meant each deployment point required 
a DAB receiver and server. 

B. Future Lmplementation 

Given the many incompatible digital audio broadcast 
standards in existance, such as IBOC (USA), DAB (Eu- 
rope) and DRM, DABml can be a common metadata lan- 
guage used across all these standards to describe the data 
content of the transmission regardless of the standard. This 
provides for an abstraction of the actual frame structure 
of the transmission, allowing a common higher-level ap- 
plication program concerned with data interpretation and 
display to be used across these standards. 

This can even be taken one step further to the devel- 
opment of a 'broadcast markup language' that will serve 
to describe content across all digital broadcast standards, 
such as DTV, DVB, XM Radio, Sirius, DAB and DRM. 
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